Network Working Group E. Davies 


Request for Comments: 4890 Consultant 
Category: Informational J. Mohacsi 
NIIF/HUNGARNET 

May 2007 


Recommendations for Filtering ICMPv6é Messages in Firewalls 


Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The IETF Trust (2007). 


Abstract 


In networks supporting IPv6, the Internet Control Message Protocol 
version 6 (ICMPv6) plays a fundamental role with a large number of 
functions, and a correspondingly large number of message types and 
options. ICMPv6é is essential to the functioning of IPv6, but there 
are a number of security risks associated with uncontrolled 
forwarding of ICMPv6 messages. Filtering strategies designed for the 
corresponding protocol, ICMP, in IPv4 networks are not directly 
applicable, because these strategies are intended to accommodate a 
useful auxiliary protocol that may not be required for correct 
functioning. 


This document provides some recommendations for ICMPv6 firewall 
filter configuration that will allow propagation of ICMPv6 messages 
that are needed to maintain the functioning of the network but drop 
messages that are potential security risks. 
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1. Introduction 


When a network supports IPv6 [RFC2460], the Internet Control Message 
Protocol version 6 (ICMPv6) [RFC4443] plays a fundamental role 
including being an essential component in establishing and 
maintaining communications both at the interface level and for 


sessions to remote nodes. This means that overly aggressive 
filtering of ICMPv6 by firewalls may have a detrimental effect on the 
establishment and maintenance of IPv6 communications. On the other 


hand, allowing indiscriminate passage of all ICMPv6 messages can be a 
major security risk. This document recommends a set of rules that 
seek to balance effective IPv6 communication against the needs of 
site security. 


In a few cases, the appropriate rules will depend on whether the 
firewall is protecting 


o an individual host, 


o an end site where all ICMPv6 messages originate or terminate 
within the site, or 


o atransit site such as an Internet Service Provider’s site where 
some ICMPv6 messages will be passing through. 


The document suggests alternative rules appropriate to each situation 
where it is relevant. It also notes some situations where 
alternative rules could be adopted according to the nature of the 
work being carried out on the site and consequent security policies. 
In general, Internet Service Providers should not filter ICMPv6 
messages transiting their sites so that all the necessary 
communication elements are available to their customers to decide and 
filter according to their policy. 


Readers familiar with ICMPv6 can skip to the recommended filtering 


rules in Section 4 and an example configuration script for Linux 
Netfilter in Appendix B. 
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ICMPv6 has a large number of functions defined in a number of sub- 
protocols, and there are a correspondingly large number of messages 
and options within these messages. The functions currently defined 
fall into a number of categories: 


Returning Error Messages 
* Returning error messages to the source if a packet could not 


be delivered. Four different error messages, each with a 
number of sub-types, are specified in [RFC4443]. 


Connection Checking 


* Simple monitoring of connectivity through echo requests and 


responses used by the ping and traceroute utilities. The 
Echo Request and Echo Response messages are specified in 
[RFC4443]. 


Discovery Functions 


* Finding neighbors (both routers and hosts) connected to the 
same link and determining their IP and link layer addresses. 
These messages are also used to check the uniqueness of any 
addresses that an interface proposes to use (Duplicate 


Address Detection - DAD). Four messages -- Neighbor 
Solicitation (NS), Neighbor Advertisement (NA), Router 
Solicitation (RS) and Router Advertisement (RA) -- are 


specified in [RFC2461]. 


* Ensuring that neighbors remain reachable using the same IP 
and link layer addresses after initial discovery (Neighbor 
Unreachability Discovery - NUD) and notifying neighbors of 
changes to link layer addresses. Uses NS and NA [RFC2461]. 


* Finding routers and determining how to obtain IP addresses 
to join the subnets supported by the routers. Uses RS and 
RA [RFC2461]. 


* If stateless autoconfiguration of hosts is enabled, 
communicating prefixes and other configuration information 
(including the link Maximum Transmission Unit (MTU) and 
suggested hop limit default) from routers to hosts. Uses RS 
and RA [RFC2462]. 


* When using SEcure Neighbor Discovery (SEND) to authenticate 
a router attached to a link, the Certificate Path 
Solicitation and Advertisement messages specified in 
[RFC3971] are used by hosts to retrieve the certificates 
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documenting the trust chain between a trust anchor and the 
router from the router. 


Determining the MTU along a path. The Packet Too Big error 
message is essential to this function [RFC1981]. 


Providing a means to discover the IPv6 addresses associated 
with the link layer address of an interface (the inverse of 
Neighbor Discovery, where the link layer address is 


discovered given an IPv6 address). Two messages, Inverse 
Neighbor Discovery Solicitation and Advertisement messages, 
are specified in [RFC3122]. 


Communicating which multicast groups have listeners ona 
link to the multicast capable routers connected to the link. 
Uses messages Multicast Listener Query, Multicast Listener 
Report (two versions), and Multicast Listener Done (protocol 
version 1 only) as specified in Multicast Listener Discovery 
MLDv1 [RFC2710] and MLDv2 [RFC3810]. 


Discovering multicast routers attached to the local link. 
Uses messages Multicast Router Advertisement, Multicast 
Router Solicitation, and Multicast Router Termination as 
specified in Multicast Router Discovery [RFC4286]. 


Reconfiguration Functions 


* 


Redirecting packets to a more appropriate router on the 
local link for the destination address or pointing out that 
a destination is actually on the local link even if it is 
not obvious from the IP address (where a link supports 
multiple subnets). The Redirect message is specified in 
[RFC2461]. 


Supporting renumbering of networks by allowing the prefixes 
advertised by routers to be altered. Uses NS, NA, RS and RA 
together with the Router Renumbering message specified in 
[RFC2894]. 


Mobile IPv6 Support 


* 


Providing support for some aspects of Mobile IPv6 especially 
dealing with the IPv6 Mobile Home Agent functionality 
provided in routers and needed to support a Mobile node 
homed on the link. The Home Agent Address Discovery Request 
and Reply and the Mobile Prefix Solicitation and 
Advertisement messages are specified in [RFC3775]. 
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Experimental Extensions 


* An experimental extension to ICMPv6é specifies the ICMP Node 
Information Query and Response messages that can be used to 
retrieve some basic information about nodes [RFC4620]. 


* The SEAmless IP MOBility (SEAMOBY) working group specified a 
pair of experimental protocols that use an ICMPv6 message 
specified in [RFC4065] to help in locating an access router 
and moving the attachment point of a mobile node from one 
access router to another. 


Many of these messages should only be used in a link-local context 
rather than end-to-end, and filters need to be concerned with the 
type of addresses in ICMPv6 packets as well as the specific source 
and destination addresses. 


Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be 
treated as an auxiliary function with packets that can be dropped in 
most cases without damaging the functionality of the network. This 
means that firewall filters for ICMPv6 have to be more carefully 
configured than was the case for ICMP, where typically a small set of 
blanket rules could be applied. 


2. Classifying ICMPv6 Messages 
2.1. Error and Informational ICMPv6 Messages 


ICMPv6 messages contain an eight-bit Type field interpreted as an 
integer between 0 and 255. Messages with Type values less than or 
equal to 127 are Error messages. The remainder are Informational 
messages. In general terms, Error messages with well-known 
(standardized) Type values would normally be expected to be allowed 
to be sent to or pass through firewalls, and may be essential to the 
establishment and maintenance of communications (see Section 2.4) 
whereas Informational messages will generally be the subject of 
policy rules, and those passing through end site firewalls can, in 
many but by no means all cases, be dropped without damaging IPv6 
communications. 


2.2. Addressing of ICMPv6 


ICMPv6 messages are sent using various kinds of source and 


destination address types and scopes. The source address is usually 
a unicast address, but during address autoconfiguration message 
exchanges, the unspecified address (::) is also used as a source 


address [RFC2462]. 
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Multicast Listener Discovery (MLD) Report and Done messages are sent 
with a link-local address as the IPv6 source address, if a valid 


address is available on the interface. If a valid link-local address 
is not available (e.g., one has not been configured), the message is 
sent with the unspecified address (::) as the IPv6 source address. 


Subsequently, the node will generate new MLD Report messages with 
proper link-local source address once it has been configured 
[RFC3590]. 


The destination address can be either a well-known multicast address, 
a generated multicast address such as the solicited-node multicast 
address, an anycast address, or a unicast address. While many ICMPv6 
messages use multicast addresses most of the time, some also use 
unicast addresses. For instance, the Router Advertisement messages 
are sent to the all-nodes multicast address when unsolicited, but can 
also be sent to a unicast address in response to a specific Router 
Solicitation, although this is rarely seen in current 
implementations. 


2.3. Network Topology and Address Scopes 


ICMPv6 messages can be classified according to whether they are meant 
for end-to-end communications or local communications within a link. 
There are also messages that we can classify as ’any-to-end’, which 
can be sent from any point within a path back to the source; 
typically, these are used to announce an error in processing the 
original packet. For instance, the address resolution messages are 
solely for local communications [RFC2461], whereas the Destination 
Unreachable messages are any-to-end in nature. Generally, end-to-end 
and any-to-end messages might be expected to pass through firewalls 
depending on policies but local communications must not. 


Local communications will use link-local addresses in many cases but 
may also use global unicast addresses when configuring global 
addresses, for example. Also, some ICMPv6 messages used in local 
communications may contravene the usual rules requiring compatible 
scopes for source and destination addresses. 


2.4. Role in Establishing and Maintaining Communication 


Many ICMPv6é messages have a role in establishing or maintaining 
communications to and from the firewall and such messages have to be 
accepted by firewalls for local delivery. Generally, a firewall will 
also be acting as a router so that all the messages that might be 
used in configuring a router interface need to be accepted and 
generated. These messages should not transit through a firewall that 
is also acting as a router as they are normally intended for use 
within a link. 
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On the other hand, most ICMPv6 error messages traveling end-to-end or 
any-to-end are essential to the establishment and maintenance of 
communications. These messages must be passed through firewalls and 
might also be sent to and from firewalls to assist with establishment 
and maintenance of communications. For example, the Packet Too Big 
error message is needed to determine the MTU along a path both when a 
communication session is established initially and later if the path 
is rerouted during the session. 


The remaining ICMPv6 messages that are not associated with 
communication establishment or maintenance will normally be 
legitimately attempting to pass through a firewall from inside to out 
or vice versa, but in most cases decisions as to whether or not to 
allow them to pass can be made on the basis of local policy without 
interfering with IPv6 communications. 


The filtering rules for the various message roles will generally be 
different. 


3. Security Considerations 


This memo recommends filtering configurations for firewalls designed 
to minimize the security vulnerabilities that can arise in using the 
many different sub-protocols of ICMPv6 in support of IPv6 
communication. 


A major concern is that it is generally not possible to use IPsec or 
other means to authenticate the sender and validate the contents of 
many ICMPv6 messages. To a large extent, this is because a site can 
legitimately expect to receive certain error and other messages from 
almost any location in the wider Internet, and these messages may 
occur as a result of the first message sent to a destination. 
Establishing security associations with all possible sources of 
ICMPv6 messages is therefore impossible. 


The inability to establish security associations to protect some 
messages that are needed to establish and maintain communications 
means that alternative means have to be used to reduce the 
vulnerability of sites to ICMPv6-based attacks. The most common way 
of doing this is to establish strict filtering policies in site 
firewalls to limit the unauthenticated ICMPv6 messages that can pass 
between the site and the wider Internet. This makes control of 
ICMPv6 filtering a delicate balance between protecting the site by 
dropping some of the ICMPv6é traffic passing through the firewall and 
allowing enough of the traffic through to make sure that efficient 
communication can be established. 
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SEND [RFC3971] has been specified as a means to improve the security 
of local ICMPv6 communications. SEND sidesteps security association 
bootstrapping problems that would result if IPsec was used. SEND 
affects only link-local messages and does not limit the filtering 
that firewalls can apply, and its role in security is therefore not 
discussed further in this document. 


Firewalls will normally be used to monitor ICMPv6 to control the 
following security concerns: 


3.1. Denial-of-Service Attacks 


ICMPv6 can be used to cause a denial of service (DoS) in a number of 
ways, including simply sending excessive numbers of ICMPv6 packets to 
destinations in the site and sending error messages that disrupt 
established communications by causing sessions to be dropped. Also, 
if spurious communication establishment or maintenance messages can 
be infiltrated onto a link, it might be possible to invalidate 
legitimate addresses or disable interfaces. 


3.2. Probing 


A major security consideration is preventing attackers from probing 
the site to determine the topology and identify hosts that might be 
vulnerable to attack. Carefully crafted but, often, malformed 
messages can be used to provoke ICMPv6 responses from hosts thereby 
informing attackers of potential targets for future attacks. 
However, the very large address space of IPv6 makes probing a less 
effective weapon as compared with IPv4 provided that addresses are 
not allocated in an easily guessable fashion. This subject is 
explored in more depth in [SCAN-IMP]. 


3.3. Redirection Attacks 


A redirection attack could be used by a malicious sender to perform 
man-in-the-middle attacks or divert packets either to a malicious 
monitor or to cause DoS by blackholing the packets. These attacks 
would normally have to be carried out locally on a link using the 
Redirect message. Administrators need to decide if the improvement 
in efficiency from using Redirect messages is worth the risk of 
malicious use. Factors to consider include the physical security of 
the link and the complexity of addressing on the link. For example, 
on an open wireless link, redirection would be a serious hazard due 
to the lack of physical security. On the other hand, with a wired 
link in a secure building with complex addressing and redundant 
routers, the efficiency gains might well outweigh the small risk of a 
rogue node being connected. 
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3.4. Renumbering Attacks 


Spurious Renumbering messages can lead to the disruption of a site. 
Although Renumbering messages are required to be authenticated with 
IPsec, so that it is difficult to carry out such attacks in practice, 
they should not be allowed through a site boundary firewall. On the 
other hand, a site may employ multiple "layers" of firewalls. In 
this case, Renumbering messages might be expected to be allowed to 
transit interior firewalls but not pass across the outer boundary. 


3.5. Problems Resulting from ICMPv6 Transparency 


Because some ICMPv6 error packets need to be passed through a 
firewall in both directions, malicious users can potentially use 
these messages to communicate between inside and outside, bypassing 
administrative inspection. For example, it might be possible to 
carry out a covert conversation through the payload of ICMPv6 error 
messages or tunnel inappropriate encapsulated IP packets in ICMPv6 
error messages. This problem can be alleviated by filtering ICMPv6 
errors using a deep packet inspection mechanism to ensure that the 
packet carried as a payload is associated with legitimate traffic to 
or from the protected network. 


4. Filtering Recommendations 


When designing firewall filtering rules for ICMPv6, the rules can be 
divided into two classes: 


o Rules for ICMPv6é traffic transiting the firewall, with some minor 
variations for 


* firewalls protecting end sites or individual hosts, and 

* firewalls protecting transit sites 
o Rules for ICMPv6 directed to interfaces on the firewall 
Firewalls integrated with an individual host ("end host firewalls") 
can be treated as end site firewalls, but the special considerations 


discussed in Section 4.2 may be relevant because the firewall is not 
a router. 
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This section suggests some common considerations that should be borne 
in mind when designing filtering rules and then categorizes the rules 
for each class. The categories are: 


o Messages that must not be dropped: usually because establishment 
or maintenance of communications will be prevented or severely 
impacted. 


o Messages that should not be dropped: administrators need to have a 
very good reason for dropping this category. 


o Messages that may be dropped in firewall/routers, but these 
messages may already be targeted to drop for other reasons (e.g., 
because they are using link-local addresses) or because the 
protocol specification would cause the messages to be rejected if 
they had passed through a router. Special considerations apply to 
transit traffic if the firewall is not a router as discussed in 
Section 4.2. 


o Messages that administrators may or may not want to drop depending 
on local policy. 


o Messages that administrators should consider dropping (e.g., ICMP 
node information name lookup queries). 


More detailed analysis of each of the message types can be found in 
Appendix A. 


4.1. Common Considerations 


Depending on the classification of the message to be filtered (see 
Section 2), ICMPv6 messages should be filtered based on the ICMPv6 


type of the message and the type (unicast, multicast, etc.) and scope 
(link-local, global unicast, etc.) of source and destination 
addresses. In some cases, it may be desirable to filter on the Code 


field of ICMPv6 error messages. 


Messages that can be authenticated on delivery, probably because they 
contain an IPsec AH header or ESP header with authentication, may be 
subject to less strict policies than messages that cannot be 
authenticated. In the remainder of this section, we are generally 
considering what should be configured for unauthenticated messages. 
In many cases, it is not realistic to expect more than a tiny 
fraction of the messages to be authenticated. 


Where messages are not essential to the establishment or maintenance 


of communications, local policy can be used to determine whether a 
message should be allowed or dropped. 
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Depending on the capabilities of the firewall being configured, it 
may be possible for the firewall to maintain state about packets that 
may result in error messages being returned or about ICMPv6 packets 
(e.g., Echo Requests) that are expected to receive a specific 
response. This state may allow the firewall to perform more precise 
checks based on this state, and to apply limits on the number of 
ICMPv6 packets accepted incoming or outgoing as a result of a packet 
traveling in the opposite direction. The capabilities of firewalls 
to perform such stateful packet inspection vary from model to model, 
and it is not assumed that firewalls are uniformly capable in this 
respect. 


Firewalls that are able to perform deep packet inspection may be able 
to check the header fields in the start of the errored packet that is 
carried by ICMPv6 error messages. If the embedded packet has a 
source address that does not match the destination of the error 
message, the packet can be dropped. This provides a partial defense 
against some possible attacks on TCP that use spoofed ICMPv6 error 
messages, but the checks can also be carried out at the destination. 
For further information on these attacks see [ICMP-ATTACKS]. 


In general, the scopes of source and destination addresses of ICMPv6 
messages should be matched, and packets with mismatched addresses 
should be dropped if they attempt to transit a router. However, some 
of the address configuration messages carried locally on a link may 
legitimately have mismatched addresses. Node implementations must 
accept these messages delivered locally on a link, and administrators 
should be aware that they can exist. 


ICMPv6 messages transiting firewalls inbound to a site may be treated 
differently depending on whether they are addressed to a node on the 
site or to some other node. For end sites, packets addressed to 
nodes not on the site should be dropped, but would generally be 
forwarded by firewalls on transit sites. 


4.2. Interaction of Link-Local Messages with Firewall/Routers and 
Firewall/Bridges 


Firewalls can be implemented both as IP routers (firewall/routers) 
and as link layer bridges (e.g., Ethernet bridges) that are 
transparent to the IP layer although they will actually be inspecting 
the IP packets as they pass through (firewall/bridges). 


Many of the messages used for establishment and maintenance of 
communications on the local link will be sent with link-local 
addresses for at least one of their source and destination. Routers 
conforming to the IPv6 standards will not forward these packets; 
there is no need to configure additional rules to prevent these 
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packets traversing a firewall/router, although administrators may 
wish to configure rules that would drop these packets for insurance 
and as a means of monitoring for attacks. Also, the specifications 
of ICMPv6 messages intended for use only on the local link specify 
various measures that would allow receivers to detect if the message 
had passed through a router, including: 


o Requiring that the hop limit in the IPv6 header is set to 255 on 
transmission. Receivers verify that the hop limit is still 255, 
to ensure that the packet has not passed through a router. 


o Checking that the source address is a link-local unicast address. 


Accordingly, it is not essential to configure firewall/router rules 
to drop out-of-specification packets of these types. If they have 
non-link-local source and destination addresses, allowing them to 
traverse the firewall/router, they would be rejected because of the 
checks performed at the destination. Again, firewall administrators 
may still wish to configure rules to log or drop such out-of- 
specification packets. 


For firewall/bridges, slightly different considerations apply. The 
physical links on either side of the firewall/bridge are treated as a 
single logical link for the purposes of IP. Hence, the link local 
messages used for discovery functions on the link must be allowed to 
transit the transparent bridge. Administrators should ensures that 
routers and hosts attached to the link containing the firewall/bridge 
are built to the correct specifications so that out-of-specification 
packets are actually dropped as described in the earlier part of this 
section. 


An end host firewall can generally be thought of as a special case of 
a firewall/bridge, but the only link-local messages that need to be 
allowed through are those directed to the host’s interface. 


4.3. Recommendations for ICMPv6 Transit Traffic 


This section recommends rules that should be applied to ICMPv6 
traffic attempting to transit a firewall. 
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4.3.1. Traffic That Must Not Be Dropped 


Error messages that are essential to the establishment and 


maintenance of communications: 


o Destination Unreachable (Type 1) - All codes 

o Packet Too Big (Type 2) 

o Time Exceeded (Type 3) - Code 0 only 

o Parameter Problem (Type 4) - Codes 1 and 2 only 


May 2007 


Appendix A.4 suggests some more specific checks that could be 
performed on Parameter Problem messages if a firewall has the 


necessary packet inspection capabilities. 
Connectivity checking messages: 


o Echo Request (Type 128) 
o Echo Response (Type 129) 


For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be 
possible, it is essential that the connectivity checking messages are 
allowed through the firewall. It has been common practice in IPv4 
networks to drop Echo Request messages in firewalls to minimize the 
risk of scanning attacks on the protected network. As discussed in 
Section 3.2, the risks from port scanning in an IPv6 network are much 
less severe, and it is not necessary to filter IPv6 Echo Request 


messages. 
4.3.2. Traffic That Normally Should Not Be Dropped 
Error messages other than those listed in Section 4.3.1: 


o Time Exceeded (Type 3) - Code 1 
o Parameter Problem (Type 4) - Code 0 


Mobile IPv6é messages that are needed to assist mobility: 


Home Agent Address Discovery Request (Type 144) 
Home Agent Address Discovery Reply (Type 145) 
Mobile Prefix Solicitation (Type 146) 

Mobile Prefix Advertisement (Type 147) 


o0o000 


Administrators may wish to apply more selective rules as described in 
Appendix A.14 depending on whether the site is catering for mobile 
nodes that would normally be at home on the site and/or foreign 


mobile nodes roaming onto the site. 
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4.3.3. Traffic That Will Be Dropped Anyway -- No Special Attention 
Needed 


The messages listed in this section are all involved with local 
management of nodes connected to the logical link on which they were 
initially transmitted. All these messages should never be propagated 
beyond the link on which they were initially transmitted. If the 
firewall is a firewall/bridge rather than a firewall/router, these 
messages should be allowed to transit the firewall as they would be 
intended for establishing communications between the two physical 
parts of the link that are bridged into a single logical link. 


During normal operations, these messages will have destination 
addresses, mostly link local but in some cases global unicast 
addresses, of interfaces on the local link. No special action is 
needed to filter messages with link-local addresses in a firewall/ 
router. As discussed in Section 4.1, these messages are specified so 
that either the receiver is able to check that the message has not 
passed through a router or it will be dropped at the first router it 
encounters. 


Administrators may also wish to consider providing rules in firewall/ 
routers to catch illegal packets sent with hop limit = 1 to avoid 
ICMPv6 Time Exceeded messages being generated for these packets. 


Address Configuration and Router Selection messages (must be received 
with hop limit = 255): 


Router Solicitation (Type 133) 

Router Advertisement (Type 134) 

Neighbor Solicitation (Type 135) 

Neighbor Advertisement (Type 136) 

Redirect (Type 137) 

Inverse Neighbor Discovery Solicitation (Type 141) 
Inverse Neighbor Discovery Advertisement (Type 142) 


000000 0 


Link-local multicast receiver notification messages (must have link- 
local source address): 


Listener Query (Type 130) 
Listener Report (Type 131) 
Listener Done (Type 132) 
Listener Report v2 (Type 143) 


o0o0°0 
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SEND Certificate Path notification messages (must be received with 
hop limit = 255): 


o Certificate Path Solicitation (Type 148) 
o Certificate Path Advertisement (Type 149) 


Multicast Router Discovery messages (must have link-local source 
address and hop limit = 1): 


o Multicast Router Advertisement (Type 151) 
o Multicast Router Solicitation (Type 152) 
o Multicast Router Termination (Type 153) 


-4. Traffic for Which a Policy Should Be Defined 


The message type that the experimental Seamoby protocols are using 
will be expected to have to cross site boundaries in normal 
operation. Transit sites must allow these messages to transit the 
site. End site administrators should determine if they need to 
support these experiments and otherwise messages of this type should 
be dropped: 


o Seamoby Experimental (Type 150) 


Error messages not currently defined by IANA: 
o Unallocated Error messages (Types 5-99 inclusive and 102-126 
inclusive) 


The base ICMPv6 specification suggests that error messages that are 
not explicitly known to a node should be forwarded and passed to any 
higher-level protocol that might be able to interpret them. There is 
a small risk that such messages could be used to provide a covert 
channel or form part of a DoS attack. Administrators of end sites 
should be aware of this and determine whether they wish to allow 
these messages through the firewall. Firewalls protecting transit 
sites must allow all types of error messages to transit the site but 
may adopt different policies for error messages addressed to nodes 
within the site. 


All informational messages with types not explicitly assigned by 
IANA, currently: 


o Unallocated Informational messages (Types 154-199 inclusive and 
202-254 inclusive). 


Note that the base ICMPv6 specification requires that received 
informational messages with unknown types must be silently discarded. 
Transit sites must allow these messages to transit the site. End 
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4. 


3. 


site administrators can either adopt a policy of allowing all these 
messages through the firewall, relying on end hosts to drop 
unrecognized messages, or drop all such messages at the firewall. 
Different policies could be adopted for inbound and outbound 
messages. 


If administrators choose to implement policies that drop currently 
unallocated error or informational messages, it is important to 
review the set of messages affected in case new message types are 
assigned by IANA. 


5. Traffic That Should Be Dropped Unless a Good Case Can Be Made 


Node Information enquiry messages should generally not be forwarded 
across site boundaries. Some of these messages will be using non- 
link-local unicast addresses so that they will not necessarily be 
dropped by address scope limiting rules: 


o Node Information Query (Type 139) 
o Node Information Response (Type 140) 


Router Renumbering messages should not be forwarded across site 
boundaries. As originally specified, these messages may use a site 
scope multicast address or a site local unicast address. They should 
be caught by standard rules that are intended to stop any packet with 
a multicast site scope or site local destination being forwarded 
across a site boundary provided these are correctly configured. 

Since site local addresses have now been deprecated, it seems likely 
that changes may be made to allow the use of unique local addresses 
or global unicast addresses. Should this happen, it will be 
essential to explicitly filter these messages at site boundaries. If 
a site has internal as well as boundary firewalls, individual 
policies should be established for the internal firewalls depending 
on whether or not the site wishes to use Router Renumbering: 


o Router Renumbering (Type 138) 
Messages with types in the experimental allocations: 
o Types 100, 101, 200, and 201. 


Messages using the extension type numbers until such time as ICMPv6 
needs to use such extensions: 


o Types 127 and 255. 
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4.4. Recommendations for ICMPv6 Local Configuration Traffic 


This section recommends filtering rules for ICMPv6 traffic addressed 
to an interface on a firewall. For a small number of messages, the 
desired behavior may differ between interfaces on the site or private 
side of the firewall and the those on the public Internet side of the 
firewall. 


4.4.1. Traffic That Must Not Be Dropped 


Error messages that are essential to the establishment and 
maintenance of communications: 


o Destination Unreachable (Type 1) - All codes 

o Packet Too Big (Type 2) 

o Time Exceeded (Type 3) - Code 0 only 

o Parameter Problem (Type 4) - Codes 1 and 2 only 


Connectivity checking messages: 


o Echo Request (Type 128) 
o Echo Response (Type 129) 


As discussed in Section 4.3.1, dropping connectivity checking 
messages will prevent the firewall being the destination of a Teredo 
tunnel and it is not considered necessary to disable connectivity 
checking in IPv6 networks because port scanning is less of a security 
risk. 


There are a number of other sets of messages that play a role in 
configuring the node and maintaining unicast and multicast 
communications through the interfaces of a node. These messages must 
not be dropped if the node is to successfully participate in an IPv6 
network. The exception to this is the Redirect message for which an 
explicit policy decision should be taken (see Section 4.4.4). 


Address Configuration and Router Selection messages: 


Router Solicitation (Type 133) 

Router Advertisement (Type 134) 

Neighbor Solicitation (Type 135) 

Neighbor Advertisement (Type 136) 

Inverse Neighbor Discovery Solicitation (Type 141) 
Inverse Neighbor Discovery Advertisement (Type 142) 


000000 
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Link-Local Multicast Receiver Notification messages: 


Listener Query (Type 130) 
Listener Report (Type 131) 
Listener Done (Type 132) 
Listener Report v2 (Type 143) 


o0o00°0 


SEND Certificate Path Notification messages: 


o Certificate Path Solicitation (Type 148) 
o Certificate Path Advertisement (Type 149) 


Multicast Router Discovery messages: 

o Multicast Router Advertisement (Type 151) 
o Multicast Router Solicitation (Type 152) 
o Multicast Router Termination (Type 153) 


4.4.2. Traffic That Normally Should Not Be Dropped 


Error messages other than those listed in Section 4.4.1: 


o Time Exceeded (Type 3) - Code 1 
o Parameter Problem (Type 4) - Code 0 
4.4.3. Traffic That Will Be Dropped Anyway -- No Special Attention 
Needed 


Router Renumbering messages must be authenticated using IPsec, so it 
is not essential to filter these messages even if they are not 
allowed at the firewall/router: 


o Router Renumbering (Type 138) 

Mobile IPv6 messages that are needed to assist mobility: 
Home Agent Address Discovery Request (Type 144) 

Home Agent Address Discovery Reply (Type 145) 


Mobile Prefix Solicitation (Type 146) 
Mobile Prefix Advertisement (Type 147) 


0000 


It may be desirable to drop these messages, especially on public 
interfaces, if the firewall is not also providing mobile home agent 
services, but they will be ignored otherwise. 
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The message used by the experimental Seamoby protocols may be dropped 
but will be ignored if the service is not implemented: 


o Seamoby Experimental (Type 150) 
4.4.4. Traffic for Which a Policy Should Be Defined 


Redirect messages provide a significant security risk, and 
administrators should take a case-by-case approach to whether 
firewalls, routers in general, and other nodes should accept these 
messages: 


o Redirect (Type 137) 


Conformant nodes must provide configuration controls that allow nodes 
to control their behavior with respect to Redirect messages so that 
it should only be necessary to install specific filtering rules under 
special circumstances, such as if Redirect messages are accepted on 
private interfaces but not public ones. 


If a node implements the experimental Node Information service, the 
administrator needs to make an explicit decision as to whether the 
node should respond to or accept Node Information messages on each 
interface: 


o Node Information Query (Type 139) 
o Node Information Response (Type 140) 


It may be possible to disable the service on the node if it is not 
wanted, in which case these messages will be ignored and no filtering 
is necessary. 


Error messages not currently defined by IANA: 


o Unallocated Error messages (Types 5-99 inclusive and 102-126 
inclusive) 


The base ICMPv6 specification suggests that error messages that are 
not explicitly known to a node should be forwarded and passed to any 
higher-level protocol that might be able to interpret them. There is 
a small risk that such messages could be used to provide a covert 
channel or form part of a DoS attack. Administrators should be aware 
of this and determine whether they wish to allow these messages to be 
sent to the firewall. 
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4. 


6. 


6. 


4.5. Traffic That Should Be Dropped Unless a Good Case Can Be Made 
Messages with types in the experimental allocations: 
o Types 100, 101, 200, and 201. 


Messages using the extension type numbers until such time as ICMPv6 
needs to use such extensions: 


o Types 127 and 255. 


All informational messages with types not explicitly assigned by 
IANA, currently: 


o Types 154-199 inclusive and 202-254 inclusive. 


Note that the base ICMPv6 specification requires that received 
informational messages with unknown types must be silently discarded. 
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Appendix A. Notes on Individual ICMPv6 Messages 


A.1. Destination Unreachable Error Message 


Destination Unreachable (Type 1) error messages [RFC4443] are sent 
any-to-end between unicast addresses. The message can be generated 
from any node that a packet traverses when the node is unable to 
forward the packet for any reason except congestion. 


Destination Unreachable messages are useful for debugging, but are 
also important to speed up cycling through possible addresses, as 
they can avoid the need to wait through timeouts and hence can be 
part of the process of establishing or maintaining communications. 

It is a common practice in IPv4 to refrain from generating ICMP 
Destination Unreachable messages in an attempt to hide the networking 
topology and/or service structure. The same idea could be applied to 
IPv6, but this can slow down connection if a host has multiple 
addresses, some of which are deprecated, as they may be when using 
privacy addresses [RFC3041]. If policy allows the generation of 
ICMPv6 Destination Unreachable messages, it is important that nodes 
provide the correct reason code, one of: no route to destination, 
administratively prohibited, beyond scope of source address, address 
unreachable, port unreachable, source address failed ingress/egress 
policy, or reject route to destination. 


A.2. Packet Too Big Error Message 


Packet Too Big (Type 2) error messages [RFC4443] are sent any-to-end 
between unicast addresses. The message can be generated from any 
node that a packet traverses on the path when the node is unable to 
forward the packet because the packet is too large for the MTU of the 
next link. This message is vital to the correct functioning of Path 
MTU Discovery and hence is part of the establishment and maintenance 


of communications. Since routers are not allowed to fragment 
packets, informing sources of the need to fragment large packets is 
more important than for IPv4. If these messages are not generated 


when appropriate, hosts will continue to send packets that are too 
large or may assume that the route is congested. Effectively, parts 
of the Internet will become inaccessible. 


If a network chooses to generate packets that are no larger than the 
Guaranteed Minimum MTU (1280 octets) and the site’s links to the 
wider Internet have corresponding MTUs, Packet Too Big messages 
should not be expected at the firewall and could be dropped if they 
arrive. 
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A.3. Time Exceeded Error Message 


Time Exceeded (Type 3) error messages [RFC4443] can occur in two 
contexts: 


o Code 0 are generated at any node on the path being taken by the 
packet and sent, any-to-end between unicast addresses, if the Hop 
Limit value is decremented to zero at that node. 


o Code 1 messages are generated at the destination node and sent 
end-to-end between unicast addresses if all the segments of a 
fragmented message are not received within the reassembly time 
limit. 


Code 0 messages can be needed as part of the establishment of 
communications if the path to a particular destination requires an 
unusually large number of hops. 


Code 1 messages will generally only result from congestion in the 
network, and it is less essential to propagate these messages. 


A.4. Parameter Problem Error Message 


The great majority of Parameter Problem (Type 4) error messages will 
be generated by the destination node when processing destination 
options and other extension headers, and hence are sent end-to-end 
between unicast addresses. Exceptionally, these messages might be 
generated by any node on the path if a faulty or unrecognized hop-by- 
hop option is included or from any routing waypoint if there are 
faulty or unrecognized destination options associated with a Type 0 
routing header. In these cases, the message will be sent any-to-end 
using unicast source and destination addresses. 


Parameter Problem Code 1 (Unrecognized Next Header) and Code 2 
(Unrecognized IPv6 Option) messages may result if a node on the path 
(usually the destination) is unable to process a correctly formed 
extension header or option. If these messages are not returned to 
the source, communication cannot be established, as the source would 
need to adapt its choice of options probably because the destination 
does not implement these capabilities. Hence, these messages need to 
be generated and allowed for effective IPv6 communications. 


Code 0 (Erroneous Header) messages indicate a malformed extension 
header generally as a result of incorrectly generated packets. 
Hence, these messages are useful for debugging purposes, but it is 
unlikely that a node generating such packets could establish 
communications without human intervention to correct the problem. 
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Code 2 messages, only, can be generated for packets with multicast 
destination addresses. 


It is possible that attackers may seek to probe or scan a network by 
deliberately generating packets with unknown extension headers or 
options or with faulty headers. If nodes generate Parameter Problem 
error messages in all cases and these outgoing messages are allowed 
through firewalls, the attacker may be able to identify active 
addresses that can be probed further or learn about the network 
topology. The vulnerability could be mitigated whilst helping to 
establish communications if the firewall was able to examine such 
error messages in depth and was configured to only allow Parameter 
Problem messages for headers that had been standardized but were not 
supported in the protected network. If the network administrator 
believes that all nodes in the network support all legitimate 
extension headers, then it would be reasonable to drop all outgoing 
Parameter Problem messages. Note that this is not a major 
vulnerability in a well-designed IPv6 network because of the 
difficulties of performing scanning attacks (see Section 3.2). 


A.5. ICMPv6 Echo Request and Echo Response 


Echo Request (Type 128) uses unicast addresses as source addresses, 
but may be sent to any legal IPv6 address, including multicast and 
anycast addresses [RFC4443]. Echo Requests travel end-to-end. 
Similarly, Echo Responses (Type 129) travel end-to-end and would have 
a unicast address as destination and either a unicast or anycast 
address as source. They are mainly used in combination for 
monitoring and debugging connectivity. Their only role in 
establishing communication is that they are required when verifying 
connectivity through Teredo tunnels [RFC4380]: Teredo tunneling to 
IPv6 nodes on the site will not be possible if these messages are 
blocked. It is not thought that there is a significant risk from 
scanning attacks on a well-designed IPv6 network (see Section 3.2), 
and so connectivity checks should be allowed by default. 


A.6. Neighbor Solicitation and Neighbor Advertisement Messages 


ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and 
136) messages are essential to the establishment and maintenance of 
communications on the local link. Firewalls need to generate and 
accept these messages to allow them to establish and maintain 
interfaces onto their connected links. 
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Note that the address scopes of the source and destination addresses 
on Neighbor Solicitations and Neighbor Advertisements may not match. 
The exact functions that these messages will be carrying out depends 
on the mechanism being used to configure IPv6 addresses on the link 
(Stateless, Stateful, or Static configuration). 


A.7. Router Solicitation and Router Advertisement Messages 


ICMPv6 Router Solicitation and Router Advertisement (Type 133 and 
134) messages are essential to the establishment and maintenance of 
communications on the local link. Firewalls need to generate (since 
the firewall will generally be behaving as a router) and accept these 
messages to allow them to establish and maintain interfaces onto 
their connected links. 


A.8. Redirect Messages 


ICMPv6 Redirect Messages (Type 137) are used on the local link to 
indicate that nodes are actually link-local and communications need 
not go via a router, or to indicate a more appropriate first—hop 
router. Although they can be used to make communications more 
efficient, they are not essential to the establishment of 
communications and may be a security vulnerability, particularly if a 
link is not physically secured. Conformant nodes are required to 
provide configuration controls that suppress the generation of 
Redirect messages and allow them to be ignored on reception. Using 
Redirect messages on, for example, a wireless link without link level 
encryption/authentication is particularly hazardous because the link 
is open to eavesdropping and packet injection. 


A.9. SEND Certificate Path Messages 


SEND [RFC3971] uses two messages (Certificate Path Solicitation and 
Advertisement - Types 148 and 149) sent from nodes to supposed 
routers on the same local link to obtain a certificate path that will 
allow the node to authenticate the router’s claim to provide routing 
services for certain prefixes. If a link connected to a firewall/ 
router is using SEND, the firewall must be able to exchange these 
messages with nodes on the link that will use its routing services. 


A.10. Multicast Listener Discovery Messages 


Multicast Listener Discovery (MLD) version 1 [RFC2710] (Listener 
Query, Listener Report, and Listener Done - Types 130, 131, and 132) 
and version 2 [RFC3810] (Listener Query and Listener Report version 2 
-— Types 130 and 143) messages are sent on the local link to 
communicate between multicast-capable routers and nodes that wish to 
join or leave specific multicast groups. Firewalls need to be able 
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to generate Listener messages in order to establish communications 
and may generate all the messages if they also provide multicast 
routing services. 


A.11. Multicast Router Discovery Messages 


Multicast Router Discovery [RFC4286] (Router Advertisement, Router 
Solicitation, and Router Termination - Types 151, 152, and 153) 
messages are sent by nodes on the local link to discover multicast- 
capable routers on the link, and by multicast-capable routers to 
notify other nodes of their existence or change of state. Firewalls 
that also act as multicast routers need to process these messages on 
their interfaces. 


A.12. Router Renumbering Messages 


ICMPv6 Router Renumbering (Type 138) command messages can be received 
and results messages sent by routers to change the prefixes that they 
advertise as part of Stateless Address Configuration [RFC2461], 
[RFC2462]. These messages are sent end-to-end to either the all- 
routers multicast address (site or local scope) or specific unicast 
addresses from a unicast address. 


Router Renumbering messages are required to be protected by IPsec 
authentication since they could be readily misused by attackers to 
disrupt or divert site communications. Renumbering messages should 
generally be confined to sites for this reason. 


A.13. Node Information Query and Reply 


ICMPv6 Node Information Query and Reply (Type 139 and 140) messages 
defined in [RFC4620] are sent end-to-end between unicast addresses, 
and they can also be sent to link-local multicast addresses. They 
can, in theory, be sent from any node to any other, but it would 
generally not be desirable for nodes outside the local site to be 
able to send queries to nodes within the site. Also, these messages 
are not required to be authenticated. 


A.14. Mobile IPv6 Messages 


Mobile IPv6 [RFC3775] defines four ICMPv6 messages that are used to 
support mobile operations: Home Agent Address Discovery Request, Home 
Agent Address Discovery Reply, Mobile Prefix Solicitation, and ICMP 
Mobile Prefix Advertisement (Type 144, 145, 146, and 147) messages. 
These messages are sent end-to-end between unicast addresses of a 
mobile node and its home agent. They must be expected to be sent 
from outside a site and must traverse site-boundary firewalls to 
reach the home agent in order for Mobile IPv6 to function. The two 
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A. 


Mobile prefix messages should be protected by the use of IPsec 
authentication. 


o If the site provides home agents for mobile nodes, the firewall 
must allow incoming Home Agent Address Discovery Request and 
Mobile Prefix Solicitation messages, and outgoing Home Agent 
Address Discovery Reply and ICMP Mobile Prefix Advertisement 


messages. It may be desirable to limit the destination addresses 
for the incoming messages to links that are known to support home 
agents. 


o If the site is prepared to host roaming mobile nodes, the firewall 
must allow outgoing Home Agent Address Discovery Request and 
Mobile Prefix Solicitation messages, and incoming Home Agent 
Address Discovery Reply and ICMP Mobile Prefix Advertisement 
messages. 


o Administrators may find it desirable to prevent static nodes that 
are normally resident on the site from behaving as mobile nodes by 
dropping Mobile IPv6 messages from these nodes. 


15. Unused and Experimental Messages 


A large number of ICMPv6 Type values are currently unused. These 
values have not had a specific function registered with IANA. This 
section describes how to treat messages that attempt to use these 
Type values in a way of which the network administrator (and hence 
the firewall) is not aware. 


[RFC4443] defines a number of experimental Type values for ICMPv6 
Error and Informational messages, which could be used in site- 
specific ways. These messages should be dropped by transit networks 
and at site edges. They should also not be propagated within sites 
unless the network administrator is explicitly made aware of usage. 


The codes reserved for future extension of the ICMPv6é Type space 
should currently be dropped as this functionality is as yet 
undefined. 


Any ICMPv6é Informational messages of which the firewall is not aware 
should be allowed to transit through the firewall but should not be 
accepted for local delivery on any of its interfaces. 


Unknown ICMPv6 Error messages should be allowed to pass through 
transit networks. At end site boundaries any incoming ICMPv6 Error 
messages of which the firewall is not aware may be allowed through 
the firewall in line with the specification in [RFC4443], which 
requests delivery of unknown error messages to higher-layer protocol 
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processes. However, administrators may wish to disallow forwarding 
of these incoming messages as a potential security risk. Unknown 
outgoing Error messages should be dropped as the administrator should 
be aware of all messages that could be generated on the site. 


Also, the SEAMOBY working group has had an ICMPv6 message (Type 150) 
allocated for experimental use in two protocols. This message is 
sent end-to-end and may need to pass through firewalls on sites that 
are supporting the experimental protocols. 


Appendix B. Example Script to Configure ICMPv6 Firewall Rules 


This appendix contains an example script to implement most of the 
rules suggested in this document when using the Netfilter packet 
filtering system for Linux [netfilter]. When used with IPv6, the 
‘ip6tables’ command is used to configure packet filtering rules for 
the Netfilter system. The script is targeted at a simple enterprise 
site that may or may not support Mobile IPv6. 


#!/bin/bash 

# Set of prefixes on the trusted ("inner") side of the firewall 
export INNER_PREFIXES="2001:DB8:85::/60" 

# Set of hosts providing services so that they can be made pingable 
export PINGABLE_HOSTS="2001:DB8:85::/64" 

# Configuration option: Change this to 1 if errors allowed only for 

# existing sessions 

export STATE_ENABLED=0 

# Configuration option: Change this to 1 if messages to/from link 

# local addresses should be filtered. 

# Do not use this if the firewall is a bridge. 

# Optional for firewalls that are routers. 

export FILTER_LINK_LOCAL_ADDRS=0 

# Configuration option: Change this to 0 if the site does not support 
# Mobile IPv6é Home Agents - see Appendix A.14 

export HOME_AGENTS_PRESENT=1 

# Configuration option: Change this to 0 if the site does not support 
# Mobile IPv6 mobile nodes being present on the site - 

# see Appendix A.14 

export MOBILE_NODES_PRESENT=1 


ip6étables -N icmpv6-filter 
ip6étables -A FORWARD -p icmpv6 -j icmpv6é-filter 


# Match scope of src and dest else deny 

# This capability is not provided for in base ip6tables functionality 
# An extension (agr) exists which may support it. 

#@TODOG@ 


Davies & Mohacsi Informational [Page 30] 


RFC 4890 ICMPv6 Filtering Recommendations May 2007 


# ECHO REQUESTS AND RESPONSES 
# 


# Allow outbound echo requests from prefixes which belong to the site 
for inner_prefix in SINNER_PREFIXES 
do 
ip6tables -A icmpv6é-filter -p icmpv6 -s Sinner_prefix \ 
—-icmpv6-type echo-request -j ACCEPT 
done 


# Allow inbound echo requests towards only predetermined hosts 
for pingable_host in $PINGABLE_HOSTS 
do 
ip6tables -A icmpv6-filter -p icmpv6 -d Spingable_host \ 
—-icmpv6-type echo-request -j ACCEPT 
done 


if [ "SSTATE_ENABLED" -eq "1" ] 
then 
# Allow incoming and outgoing echo reply messages 
# only for existing sessions 
ip6tables -A icmpv6é-filter -m state -p icmpvé \ 
--state ESTABLISHED, RELATED --icmpv6-type \ 
echo-reply -j ACCEPT 


else 
# Allow both incoming and outgoing echo replies 
for pingable_host in $PINGABLE_HOSTS 
do 
# Outgoing echo replies from pingable hosts 
ip6tables -A icmpv6-filter -p icmpv6 -s Spingable_host \ 
--icmpv6-type echo-reply -j ACCEPT 
done 
# Incoming echo replies to prefixes which belong to the site 
for inner_prefix in SINNER_PREFIXES 
do 
ip6tables -A icmpv6é-filter -p icmpv6 -d Sinner_prefix \ 
--icmpv6-type echo-reply -j ACCEPT 
done 
fi 


# Deny icmps to/from link local addresses 
# If the firewall is a router: 
# These rules should be redundant as routers should not forward 
# link local addresses but to be sure... 
# DO NOT ENABLE these rules if the firewall is a bridge 
if [ "SFILTER_LINK_LOCAL_ADDRS" -eq "1" ] 
then 
ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP 
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ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP 
fi 


# Drop echo replies which have a multicast address as a 

# destination 

ip6tables -A icmpv6é-filter -p icmpv6 -d ff00::/8 \ 
--icmpv6-type echo-reply -j DROP 


# DESTINATION UNREACHABLE ERROR MESSAGES 
# 


if [ "SSTATE_ENABLED" -eq "1" ] 
then 
# Allow incoming destination unreachable messages 
# only for existing sessions 
for inner_prefix in SINNER_PREFIXES 
do 
ip6tables -A icmpv6é-filter -m state -p icmpvé \ 
-d Sinner_prefix \ 
--state ESTABLISHED, RELATED --icmpv6-type \ 
destination-unreachable -j ACCEPT 


done 
else 
# Allow incoming destination unreachable messages 
for inner_prefix in SINNER_PREFIXES 
do 
ip6tables -A icmpv6é-filter -p icmpv6 -d Sinner_prefix \ 
—--icmpv6-type destination-unreachable -j ACCEPT 
done 
fi 


# Allow outgoing destination unreachable messages 
for inner_prefix in SINNER_PREFIXES 
do 
ip6tables -A icmpv6é-filter -p icmpv6 -s Sinner_prefix \ 
—--icmpv6-type destination-unreachable -j ACCEPT 
done 


# PACKET TOO BIG ERROR MESSAGES 
# 


if [ "SSTATE_ENABLED" -eq "1" ] 
then 
# Allow incoming Packet Too Big messages 
# only for existing sessions 
for inner_prefix in SINNER_PREFIXES 
do 
ip6tables -A icmpv6é-filter -m state -p icmpvé \ 
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-d Sinner_prefix \ 
--state ESTABLISHED, RELATED \ 
--icmpv6-type packet-too-big \ 
-j ACCEPT 
done 
else 
# Allow incoming Packet Too Big messages 
for inner_prefix in SINNER_PREFIXES 
do 
ip6tables -A icmpv6é-filter -p icmpv6 -d Sinner_prefix \ 
—-icmpv6-type packet-too-big -j ACCEPT 
done 
fi 


# Allow outgoing Packet Too Big messages 
for inner_prefix in SINNER_PREFIXES 
do 
ip6tables -A icmpv6é-filter -p icmpv6 -s Sinner_prefix \ 
—-icmpv6-type packet-too-big -j ACCEPT 
done 


# TIME EXCEEDED ERROR MESSAGES 


# 
if [ "SSTATE_ENABLED" -eq "1" ] 
then 
# Allow incoming time exceeded code 0 messages 
# only for existing sessions 
for inner_prefix in SINNER_PREFIXES 
do 
ip6tables -A icmpv6é-filter -m state -p icmpvé \ 
-d Sinner_prefix \ 
--state ESTABLISHED, RELATED --icmpv6-type packet-too-big \ 
-j ACCEPT 
done 
else 


# Allow incoming time exceeded code 0 messages 
for inner_prefix in SINNER_PREFIXES 
do 
ip6tables -A icmpv6é-filter -p icmpv6é -d Sinner_prefix \ 
--icmpv6-type ttl-zero-during-transit -j ACCEPT 
done 
Ea 


#@POLICY@ 

# Allow incoming time exceeded code 1 messages 
for inner_prefix in SINNER_PREFIXES 

do 
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ip6tables -A icmpv6é-filter -p icmpv6é -d Sinner_prefix \ 
—-icmpv6-type ttl-zero-during-reassembly -j ACCEPT 
done 


# Allow outgoing time exceeded code 0 messages 

for inner_prefix in SINNER_PREFIXES 

do 

ip6tables -A icmpv6é-filter -p icmpv6 -s Sinner_prefix \ 
--icmpv6-type ttl-zero-during-transit -j ACCEPT 

done 


#@POLICY@ 

# Allow outgoing time exceeded code 1 messages 

for inner_prefix in SINNER_PREFIXES 

do 

ip6tables -A icmpv6é-filter -p icmpv6 -s Sinner_prefix \ 
—-icmpv6-type ttl-zero-during-reassembly -j ACCEPT 

done 


# PARAMETER PROBLEM ERROR MESSAGES 
# 


if [ "SSTATE_ENABLED" -eq "1" ] 
then 
# Allow incoming parameter problem code 1 and 2 messages 
# for an existing session 
for inner_prefix in SINNER_PREFIXES 
do 
ip6tables -A icmpv6-filter -m state -p icmpvé \ 
-d Sinner_prefix \ 
-—-state ESTABLISHED, RELATED --icmpv6-type \ 
unknown-header-type \ 
-j ACCEPT 
ip6tables -A icmpv6-filter -m state -p icmpvé \ 
-d Sinner_prefix \ 
--state ESTABLISHED, RELATED \ 
--icmpv6-type unknown-option \ 
-j ACCEPT 


done 
fi 


# Allow outgoing parameter problem code 1 and code 2 messages 
for inner_prefix in SINNER_PREFIXES 
do 
ip6tables -A icmpv6é-filter -p icmpv6 -s Sinner_prefix \ 
—--icmpv6-type unknown-header-type -j ACCEPT 
ip6tables -A icmpv6é-filter -p icmpv6 -s Sinner_prefix \ 
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--icmpv6-type unknown-option -j ACCEPT 
done 


#@POLICY@ 

# Allow incoming and outgoing parameter 

# problem code 0 messages 

for inner_prefix in SINNER_PREFIXES 

do 

ip6tables -A icmpv6-filter -p icmpvé \ 

--icmpv6-type bad-header \ 
-j ACCEPT 

done 


# NEIGHBOR DISCOVERY MESSAGES 
# 


# Drop NS/NA messages both incoming and outgoing 
ip6tables -A icmpv6-filter -p icmpv6 \ 

—-icmpv6-type neighbor-solicitation -j DROP 
ip6tables -A icmpv6-filter -p icmpv6 \ 

—-icmpv6-type neighbor-advertisement -j DROP 


# Drop RS/RA messages both incoming and outgoing 

ip6tables -A icmpv6-filter -p icmpvé \ 
—--icmpv6-type router-solicitation -j DROP 

ip6tables -A icmpv6-filter -p icmpvé \ 
—-icmpv6-type router-advertisement -j DROP 


# Drop Redirect messages both incoming and outgoing 
ip6étables -A icmpv6-filter -p icmpv6 --icmpvé6é-type redirect -j DROP 


# MLD MESSAGES 

# Drop incoming and outgoing 

# Multicast Listener queries (MLDvl and MLDv2) 

ip6étables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP 


# Drop incoming and outgoing Multicast Listener reports (MLDv1) 
ip6étables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP 


# Drop incoming and outgoing Multicast Listener Done messages (MLDv1) 
ip6étables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP 


# Drop incoming and outgoing Multicast Listener reports (MLDv2) 
ip6étables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP 


# ROUTER RENUMBERING MESSAGES 
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# 


# Drop router renumbering messages 
ip6étables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP 


# NODE INFORMATION QUERIES 
# 


# Drop node information queries (139) and replies (140) 
ip6étables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP 
ipé6étables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP 


# MOBILE IPv6 MESSAGES 
# 


# If there are mobile ipv6 home agents present on the 
# trusted side allow 


if [ "SHOME_AGENTS_ PRESENT" -eq "1" ] 
then 
for inner_prefix in $INNER_PREFIXES 
do 


#incoming Home Agent address discovery request 

ip6tables -A icmpv6é-filter -p icmpv6 -d Sinner_prefix \ 
—-icmpv6-type 144 -j ACCEPT 

#outgoing Home Agent address discovery reply 

ip6tables -A icmpv6é-filter -p icmpv6 -s Sinner_prefix \ 
--icmpv6-type 145 -j ACCEPT 

#incoming Mobile prefix solicitation 

ip6tables -A icmpv6é-filter -p icmpv6é -d Sinner_prefix \ 
--icmpv6-type 146 -j ACCEPT 

#outgoing Mobile prefix advertisement 

ip6tables -A icmpv6é-filter -p icmpv6 -s Sinner_prefix \ 
--icmpv6-type 147 -j ACCEPT 


done 
fi 


# If there are roaming mobile nodes present on the 
# trusted side allow 


if [ "SMOBILE NODES PRESENT" -eq "1" ] 
then 
for inner_prefix in SINNER_PREFIXES 
do 


#outgoing Home Agent address discovery request 

ip6tables -A icmpv6é-filter -p icmpv6 -s Sinner_prefix \ 
--icmpv6-type 144 -j ACCEPT 

#incoming Home Agent address discovery reply 

ip6tables -A icmpv6é-filter -p icmpv6 -d Sinner_prefix \ 
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--icmpv6-type 145 -j ACCEPT 

#outgoing Mobile prefix solicitation 

ip6tables -A icmpv6é-filter -p icmpv6 -s Sinner_prefix \ 
--icmpv6-type 146 -j ACCEPT 

#incoming Mobile prefix advertisement 

ip6tables -A icmpv6é-filter -p icmpv6 -d Sinner_prefix \ 
--icmpv6-type 147 -j ACCEPT 

done 
fi 


# DROP EVERYTHING ELSE 
# 


ip6étables -A icmpv6-filter -p icmpv6 -j DROP 
Example Netfilter Configuration Script for ICMPv6 Filtering 
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